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Abstract _ _ _ _ _ 

This  document  presents  the  software  requirements  analysis  for  Travel,  Version  1.0,  a 
component  of  the  Corporate  Business  Application  Software  System  (C-BASS)  that  automates 
travel  requests  for  the  U.S.  Army  Research  Laboratory  (ARL).  The  document  follows  the 
process  of  structured  analysis,  or  step-wise  refinement  of  requirements,  as  applied  to  the 
development  of  a  prototype  for  the  full  version  of  Travel.  The  “environmental  model”  includes 
a  high-level  system  description,  followed  by  a  context  diagram  and  a  list  of  events  to  which  the 
system  must  respond.  The  “behavioral  model”  includes  a  data  flow  diagram  (DFD)  for  each  of 
the  four  Travel  1 .0  subsystems.  From  this  representation,  the  basic  functional  specifications  are 
derived  and  represented  in  structured  English  (or  program  design  language).  The  final  segment 
of  the  document  includes  a  data  dictionary  that  defines  all  data  and  control  items. 
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1.  Introduction 


Travel  Version  1 .0  is  a  component  of  the  Corporate  Business  Application  Software  System 
(C-BASS)  family  of  applications,  an  integrated  set  of  Lotus  Notes  and  Web-based  software  to 
support  U.  S.  Army  Research  Laboratory  (ARL)  electronic  workflow  and  task  automation.  The 
motivating  force  behind  the  C-BASS  project  has  been  ARL  downsizing  and  findings  elaborated 
on  in  the  Business  Process  Reengineering  (BPR)  exercises  in  organizational  change  beginning  in 
1996.  Travel  Version  1.0  is  the  second  software  deliverable  of  the  C-BASS.  Buylt  (an 
automation  of  the  small  purchase  process)  was  the  first. 

1.1  Travel  Version  1.0.  The  purpose  of  Travel  Version  1.0  (referred  to  hereafter  as 
Travel  1.0)  is  to  model  a  secure  client/server  system  that  provides  for  the  processing  of  travel 
requests  for  ARL  personnel.  This  proof-of-principle  prototype  will  alleviate  some  of  the  risks 
involved  in  implementing  new  technologies  used  to  build  fee  ARL  Intranet. 

The  essential,  top-level  requirements  for  Travel  1.0  are  described  in  fee  ARL  BPR  “To-Be 
Model:  ARL  Travel  Orders”  [1].  This  document  refines  fee  requirements  set  forth  in  that 
antecedent  report.  Figure  1  shows  fee  flow  of  fee  travel  process  based  on  fee  BPR  “To-Be 
Model:  ARL  Travel  Orders.” 

1.2  Development  Plan  and  Project  Schedule.  Development  of  a  foil  production  travel 
automated  system  will  proceed  in  phases,  using  an  incremental,  evolutionary  approach.  As 
Figure  2  indicates.  Travel  1.0  is  a  scaled-down  rendition  of  the  overall  travel  process,  which 
includes  preparing  fee  travel  request,  obtaining  approvals,  and  generating  an  electronic  travel 
packet  including  a  hard  copy  of  DD1610  and  a  Travel  Information  Sheet. 

1.3  Contents  of  This  Report.  This  document  presents  the  results  of  a  structured  system 
analysis  used  to  derive  fee  software  requirements  for  Travel  1.0,  starting  wife  fee  baseline 
requirements  given  in  fee  BPR  ‘To-Be  Model:  ARL  Travel  Orders”  [1].  The  body  of  fee  report 
contains  five  sections: 
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Figure  1.  Travel  Process  Diagram. 
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Figure  2.  Scope  of  System  Activities. 
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•  “Structured  Analysis  Overview”  -  briefly  explains  the  methodology  used  to  extract  the 
software  functional  specifications. 

•  “System  Overview”  -  describes  the  basic  Travel  1.0  concept  and  outlines  the  high-level 
requirements. 

•  “System  Requirements”  -  breaks  the  general  requirements  into  lower-level,  derived 
requirements  and  describes  each  in  detail. 

•  “Functional  Specifications”  -  discusses  the  products  of  the  structured  analysis  (i.e.,  the  data 
flow  diagrams  (DFDs)  and  stractured  English  narrative),  for  each  subsystem  of  Travel  1.0. 

•  “Data  Dictionary”  -  lists  each  of  the  Travel  1.0  data  elements,  giving  the  full  description 
and  type  for  the  data  model. 

2.  Structured  Analysis  Overview 


The  purpose  of  a  stmctured  analysis  is  to  develop  detailed  specifications  from  high-level 
requirements.  Through  a  series  of  step-wise  refinements,  primary  system  functions  are  broken 
down  into  progressively  more  detailed  levels  of  processes,  and  the  data  flows  between  these 
processes  are  defined.  Three  modeling  tools  facilitate  this  decomposition:  (1)  DFDs, 
(2)  stractured  Riglish  process  narratives  (represented  in  pseudo-code  or  program  design  language 
[PDL]),  and  (3)  a  data  dictionary  defining  each  object  (data  or  control  item). 

The  results  of  this  analytical  approach  are  systematic  elaborations  of  product  requirements, 
typically  expressed  as  two  separate  types  of  composite  models: 

•  An  environmental  model  that  defines  the  system’s  interfaces  to  the  outside  world  (see 
section  3,  “System  Overview”). 

•  A  behavioral  model  that  defines  the  internal  behavior  the  system  must  exhibit  in  order  to 
deal  with  the  environment  (see  section  4,  “System  Requirements,”  and  section  5, 
“Functional  Specifications”). 
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3.  System  Overview 


The  environmental  model  typically  consists  of  three  components:  (1)  a  concise  statement  of 
the  system’s  purpose  and  required  functionality,  (2)  a  context  diagram,  and  (3)  an  events  list. 
The  context  diagram  is  the  highest  level  DFD.  It  shows  the  system  as  a  single  process,  including 
users’  interaction  and  communication  with  external  systems,  as  well  as  data  flow  input  and 
output.  The  events  list  is  an  index  of  outside  stimuli  the  system  must  respond  to  in  order  to 
accomplish  the  purpose  of  the  system. 


3.1  Required  Functionality.  The  overall  concept  of  Travel  1.0  is  to  provide  a  secure, 
automated  means  for  the  preparation,  routing,  approval,  and  tracking  of  travel  requests.  Table  1 
lists  the  high-level  requirements  for  Travel  1.0  and  gives  a  general  description  of  what  the 
requirements  involve. 


Table  1.  High-Level  Requirements  for  Travel  Version  1.0 


Requirement 

Description 

Security 

Provide  security  measures  to  prevent  unauthorized  access  to 
the  system  and  its  data  and  keep  authorized  users  from 
performing  tasks  not  allowed  in  their  roles 

Travel  Request  Preparation 

Provide  a  means  for  the  requesters  and  functional  users  to 
input/edit  relevant  information  pertaining  to  a  travel  request 

Automated  Request  Routing 

Automate  the  process  of  travel  requests  to  the  various 
functional  areas 

Electronic  Approval 

Provide  a  means  for  designated  officials  and  functional  users 
to  electronically  approve,  reject,  or  cancel  a  travel  request 

Request  Tracking 

Allow  users  to  track  the  status  of  active  travel  requests 
currently  in  the  system  and  provide  printing  capability 

Legacy  System  Interface 

Implement  automated  interfaces  to  SOMARDS  and  ORACLE 
systems^ 

“  ORACLE  systems  are  software  solutions  produced  by  Oracle  Corps.  Standard  Operating  and  Maintenance  Army 
Research  Development  System  (SOMARDS)  is  a  Defense  Department  legacy  system. 
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3.2  Context  Diagram.  Figure  3  shows  the  context  diagram  for  Travel  1.0.  Each  outlying 
square  in  the  diagram  represents  an  external  entity  (users,  functional  areas,  and  legacy  systems) 
with  which  Travel  1.0  communicates.  The  arrows  indicate  the  data  that  flow  into  and  out  of 
Travel  1.0. 


Requester 


userid 

profilejnfo 

requestjnfo 

tr_details 

fund_source 

corrections 

cancel_1r 

requester_approval 


Inboxjnquiry 

statusjnquiry 

report_t^e 

display_detai!s 


User 


Figure  3.  Context  Diagram  for  Travel. 

A  few  elements  on  Figiure  3  need  additional  explanation.  First,  the  external  entity  “User” 
represents  all  users  of  the  system,  and  the  data  flows  associated  with  the  box  indicate  display  of 
basic  information.  Second,  all  of  the  other  external  entities  (“Requester,”  “Secretary,” 
“Supervisor”),  and  their  corresponding  data  flows  show  the  specific  information  that  is  passed  to 
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Travel  1.0  by  the  user  or  by  the  system.  Lastly,  the  data  store  EMPLOYEE  contains  user 
information,  such  as  name,  phone  number,  address,  office  symbol,  and  the  like. 


3.3  Event  List  The  following  list  contains  the  events  to  which  the  system  must  respond: 

•  Requester  defines  travel  needs  and  itinerary. 

•  Requester  prepares  travel  request. 

•  Fund  source  is  completed  at  the  office  level. 

•  Requester,  secretary,  supervisor,  or  budget  analyst  cancels  or  rejects  travel  request. 

•  Budget  analyst  approves  fund  source. 

•  Travel  1.0  generates  a  travel  order  number. 

•  SOMARDS  certifies  and  commits  funds. 

•  Ability  to  view,  review,  and  track  forms. 

•  Routing. 

•  Reporting. 

•  Requester  obtains  a  Travel  Packet  (DD1610,  Travel  Information  Sheet)  when  form  is 
completed. 

•  Email  notification. 

4.  System  Requirements 


Antecedent  studies  and  legacy  systems,  as  well  as  user-centered  task  analyses  for  business 
practices,  contribute  to  Travel  1.0’s  concept-level  requirements.  For  example,  the  “Report 
Specificiations”  [2]  and  the  “To-Be  Model:  ARL  Travel  Orders”  [1]  documents,  produced  during 
the  BPR  development  effort,  contributed  characterizations  of  core  business  processes  and 
preliminary  descriptions  of  subsystems  to  accomplish  defined  tasks.  However,  for  some  areas, 
these  documents  lack  detail;  hence,  necessary  elements  had  to  be  derived.  Additionally, 
requirements  have  been  adjusted  to  accommodate  the  constrained  scope  of  a  prototype 
implementation.  The  “Travel  Software  Development  Plan”  [3]  more  fully  addresses  the 
boundaries  of  the  prototype  and  the  impact  of  the  legacy  systems  on  Travel  1.0’s  design. 
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El  Security 

El  1  Prevent  unauthorized  access 

•  Description  —  Prevent  unauthorized  access  to  the  system  and  its  data. 

•  Source  —  Derived,  due  to  the  nature  of  the  system. 

•  Interfaces  to  major  functions  and  external  entities: 

—  User 

El  2  Enforce  role  restrictions 

•  Description  —  Prevent  users  from  performing  tasks  or  accessing/editing 
data  that  are  out  of  the  scope  of  their  role. 

•  Source  —  BPR  “To-Be  Model”  document,  Automation  Requirements 
section,  requirement. 

•  Interfaces  to  major  functions  and  external  entities: 

—  User 

—  Approvals 

—  Edits 

—  Employee  address  book  (for  roles) 

E2  Travel  request  preparation 

E2 1  Create  traveler  profile 

•  Description  —  Allow  the  requester  to  create  a  traveler  profile  with 
preliminary  user  information  filled  in. 

•  Source  —  Derived  from  the  need  for  a  more  automated  system. 

•  Interfaces  to  major  functions  and  external  entities: 

—  User 

—  Security 

—  Employee  address  book  (for  user  info.) 
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E22  Select  travel  requirements 

•  Description  —  Import  traveler  profile  data  and  provide  a  means  for  the 
user  to  enter  proceed  date,  itinerary,  purpose  of  travel,  transportation 
mode,  per  diem,  and  other  estimated  costs,  other  specific  info.,  and  fund 
source. 

•  Source  —  BPR  “To-Be  Model”  document.  Automation  Requirements 
section,  requirement  Al. 

•  Interfaces  to  major  functions  and  external  entities: 

—  User 

—  Traveler  profile 

—  Security 

E23  Select  additional  Information 

•  Description  —  Provide  means  for  the  user  to  enter  lodging  info.,  rental  car 
info.,  tdy  site  info.,  and  airline  info. 

•  Source  —  User  requested. 

•  Interfaces  to  major  functions  and  external  entities: 

—  User 

—  Security 

E24  Complete  travel  request 

•  Description  —  Provide  a  means  for  the  requester  and/or  supervisor  to 
complete  the  fund  source. 

•  Source  —  BPR  “To-Be  Model”  document.  Automation  Requirements 
section,  requirement  A2. 

•  Interfaces  to  major  functions  and  external  entities: 

—  User 

—  Security 
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E25  Edit  travel  request 

•  Description  —  Provide  a  means  for  users  to  edit  certain  request  details  as 
needed. 

.  Source  —  Derived,  due  to  the  need  for  making  corrections  to  travel 
request. 

•  hiterfaces  to  major  functions  and  external  entities: 

—  User 

—  Security 

E26  Cancel  travel  request 

•  Description  —  Provide  a  means  for  users  to  cancel  a  travel  request  as 
needed. 

•  Source  —  BPR  “To-Be  Model”  document,  Automation  Requirements 
section,  requirement  A2. 

•  Interfaces  to  major  functions  and  external  entities: 

—  User 

—  Security 

E3  Routing 

•  Description  —  Automate  the  process  of  routing  travel  requests  to  the 
various  functional  areas  and  approving  officials. 

•  Source  —  BPR  “To-Be  Model”  document.  Automation  Requirements 
section,  requirement  Al. 

•  Interfaces  to  major  functions  and  external  entities: 

—  Security 

—  Employee  address  book  (for  default  routing) 


E4  Electronic  Approval 

•  Description  —  Provide  a  means  for  approving  officials  and  functional 
users  to  approve,  reject,  or  cancel  a  travel  request. 
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•  Source  —  BPR  “To-Be  Model”  document,  Automation  Requirements 
section,  requirement  A2. 

•  Interfaces  to  major  functions  and  external  entities: 

—  User 

—  Security 

E5  Legacy  system  interfaces 

•  Description  —  Provide  an  electronic  interface  to  the  legacy  financial 
system  (SOMARDS)  that  automates  the  certification  and  commitment  of 
funds. 

•  Source  — ^To-Be  Model  section,  process  model  diagram  A3,  process  A33. 

E6  Inquiries 

E62  Status  Liquiries 

•  Description  —  Allow  users  to  track  the  status  of  active  travel  requests 
currently  in  the  system. 

•  Source  —  User  requested. 

•  Interfaces  to  major  functions  and  external  entities: 

—  User 

E63  Reports 

•  Description  —  Allow  users  to  generate  reports  and  print  DD 1610. 

E64  Print  Travel  Details 

•  Description  —  Ability  to  print  travel  details. 

E7  Navigation 

•  Description  —  Provide  users  with  a  means  for  navigating  to  the  various 
functional  areas  within  the  system. 

•  Source  —  Derived  from  the  requirements  listed  previously. 

•  Interfaces  to  major  functions  and  external  entities: 

—  User 
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5.  Functional  Specifications 


The  behavioral  model  expands  the  analytical  results  from  the  enviromnental  model  to  define 
more  fiilly  how  the  system  performs  its  prescribed  tasks.  Typical  representations  in  this  model 
are  (1)  concise  data  flow  charts  showing  how  information  is  transformed  as  it  moves  through  the 
system  and  subsystems,  (2)  a  set  of  structured  English  statements  forming  a  processing  narration 
based  on  data  types,  control  stmctures,  and  transformations,  and  (3)  a  data  dictionary  defining 
each  data  and  control  item. 

5.1  Travel  Subsystems.  The  seven  functionalities  listed  in  the  previous  section  identify  the 
major  required  functionality  of  Travel  1.0:  (1)  security,  (2)  travel  request  preparation, 

(3)  routing,  (4)  electronic  approval,  (5)  legacy  system  interfaces,  (6)  inquiries,  (7)  navigation. 
For  the  purpose  of  deriving  more  complete  software  specifications  in  this  design  exercise,  these 
preliminary  categories  are  consolidated  into  four  subsystems:  (1)  Prepare  Travel  Request, 
(2)  Approve  Funds  Process,  (3)  Inquiries,  and  (4)  Edit/Cancel  Travel  Request. 

Figure  4  shows  the  major  functional  subsystems  of  Travel  1.0,  as  represented  by  a  DFD. 
Each  of  the  four  bubbles  in  the  diagram  represents  a  major  subsystem  or  process,  with  the  arrows 
showing  the  data  flowing  into  and  out  of  the  processes. 

The  data  store  ACTIVE,  located  in  the  center  of  the  diagram,  holds  all  die  active  travel 
requests,  while  waiting  for  the  various  users  to  perform  their  functions  on  them.  The 
CANCELED  data  stores  contain  travel  requests  that  have  been  canceled.  The  small  squares 
along  the  outer  edges  of  this  DFD  are  interfaces  to  the  outside  world. 

No  process  bubble  for  security  appears  at  this  level  because  the  application  development 
environment  (i.e.,  Lotus  Notes)  handles  user  authorization  and  system  security.  Additionally, 
enforcement  of  role  restrictions  is  handled  within  each  subsystem,  as  detailed  in  section  5.2. 
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Figure  4.  Major  Subsystems  of  Travel. 

5.2  Subsystems  Data  Flow  Diagrams.  System  objects  and  operations  can  be  coherently 
represented  as  DFDs.  A  DFD  can  be  used  to  capture  system  concepts  and  components  at  any 
level  of  abstraction.  Each  of  the  following  four  DFDs  (Figures  5-8)  provides  more  detail  for  the 
information  flow  and  the  functionality  of  each  of  the  identified  Travel  1.0  subsystems. 
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Figure  5  shows  the  DFD  for  the  Prepare  Travel  Request  subsystem.  The  major  inputs  to  this 
process  (and  its  basic  functions)  are  the  requester  information  (derived  from  the  user-supplied 
userid  and  the  EMPLOYEE  data  store),  profile  information,  travel  request  information,  and 
travel  details.  The  fund  source  completes  the  information  for  the  request  and  the  requester,  and 
supervisory  approval  puts  the  request  into  the  travel  cycle. 


fundedjr 


requestedjr 


supervbory_approval 


■o 


qM 


canceL-lr 

M 


Figure  5.  Prepare  Travel  Request  Subsystem. 
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Figure  6  shows  the  DFD  for  the  Approve  Funds  subsystem.  This  subsystem,  besides  having 
interfaces  to  users  for  approvals,  also  interfaces  with  Budget  for  approvals  and  connects  to  the 
SOMARDS  legacy  system.  The  Build  Block  process  is  executed  at  the  start  of  the  day  and 
creates  the  transaction  block  that  will  be  used  by  Travel  1.0  for  the  remainder  of  the  day.  As 
travel  requests  are  created  during  the  course  of  the  day,  the  Certify  Funds  process  polls 
SOMARDS  and  grabs  the  returning  message.  Depending  on  the  results,  the  request  is  either 
certified  or  rejected  (with  explanation).  At  the  end  of  the  day,  the  Reconciled  process  is  executed 
to  balance  the  transaction  block. 


Figure  6.  Approve  Funds  Subsystem. 

Figure  7  diagrams  the  Edit/Cancel  Travel  Request  process.  The  rejected  travel  request  is 
displayed  to  the  requester  for  corrections.  Depending  on  where  the  rejection  came  from  and  how 
far  along  the  approval  process  the  request  has  traveled,  the  requester  will  only  be  allowed  to  edit 
certain  fields  within  the  form. 
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conections 


Figure  7.  Edit/Cancel  Travel  Request 

The  Inquiries  process  is  diagramed  in  Figure  8.  The  processes  shown  in  this  figure  are  used 
to  display  to  the  user  pending  actions  (inbox),  status  of  requests,  reports,  and  travel  request 
details.  The  user  also  has  the  capability  to  print  the  DD1610  and  the  Travel  Information  Sheet  at 
this  point. 


Figure  8.  Inquiries  process. 

53  Processing  Narration.  Having  captured  the  flow  of  information  and  identified  data 
objects,  each  transformation  can  be  further  expanded  by  using  the  notation  of  structured  English. 
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In  this  quasi-formalism,  basic  procedural  constructs  are  combined  with  English  phrases  to  give 
concise  descriptions  for  each  major  operation  listed  in  the  prescribed  tasks  analysis  given  in 
section  4. 

El  Security 

Ell  Login 

•  Input  —  userid,  passwd 

•  Process: 

—  REPEAT 

—  GET  from  user  the  userid,  passwd 

—  UNTIL  VALID  userid,  passwd 

—  ALLOW  login 

•  Output  —  N/A 
E12  Role 

•  Input  —  role,  action 

•  Process 

—  GET  from  EMPLOYEE  the  role  using  requester_userid 
—  IF  VALID  action  for  role  THEN 

—  EXECUTE  action 

—  ELSE 

—  NULL 

—  ENDIF 

•  Output  —  action_results 

E2  Prepare  Travel  Request 

E2 1  Create  new  traveler  profile 

•  Input  —  tr,  requester_userid,  user_info,  profile_info 

•  Process  1.1 

—  GET  from  EMPLOYEE  the  user_info  using  requester_userid 
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—  GET  from  user  traveler_ssn,  traveler_grade,  atm_status,  jo_no 
—  SET  in  tr  the  requester_userid 

—  SET  in  tr  the  user_info  using  user_info 

—  SET  in  tr  the  profile_info 

•  Output  —  blank_tr 

E22  Fill  in  travel  request 

•  Input  —  blank_tr,  purpose_tdy,  proceed_date,  itinerary_ffom,  itinerary_to, 

itinerary_ret,  poc_mode_trans,  advance_auth,  special_req,  costs 

•  Process  1.2 

—  GET  from  user  the  the  purpose_tdy 
—  GET  from  user  the  the  proceed_date 
—  GET  from  user  the  itmerary_from 
—  DO  WHILE  there  is  another  site  to  travel 
—  GET  from  user  the  itinerary_to 

—  SET  in  tr  the  itinerary_to 

—  ENDDO 

—  GET  from  user  the  itinerary_ret 

—  SET  in  tr  the  itinerary_ret 

—  GET  from  user  the  poc_mode_trans 
—  SET  in  tr  the  poc_mode_trans 

—  GET  from  user  the  advance_auth 
—  SET  in  tr  the  advance_auth 

—  GET  from  user  the  special_req 
—  SET  in  tr  the  special_req 

—  GET  from  user  the  costs 

—  SET  in  tr  the  costs 

•  Output  —  partial_tr 
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E23 


Fill  in  additional  Information 


•  Input  —  partial_tr,tdy_site_info,  lodging_info,  rental_car_info, 

airline_info 

•  Process  1.3 

—  GET  from  user  the  tdy_site_info,  lodging_info,  rentalcar_info, 
airline_mfo 

—  SET  in  tr  the  tdy_site_info,  lodging_info,  rentalcar_info, 
airline_info 

•  Output  — ^unfunded_tr 
E24  Fill  in  fund  source 

•  Input — ^unfunded_tr,  fund_source 

•  Process  1.4 

—  GET  from  user  the  fund_source 
—  SET  in  tr  the  fund_source 

•  OuQ)ut  —  funded_tr 


E25  Correct  travel  request 

•  Input  —  rejected_tr,  corrections 

•  Process  3.1 

—  DISPLAY  to  user  rejected_tr  and  explanation 

—  DO  WHILE  there  are  more  corrections 

—  GET  from  user  the  corrections 

—  SET  in  tr  the  corrections 

—  ENDDO 

•  Output  —  corrected_tr 
E26  Cancel  request 

•  Input — active_tr,  cancel_tr 

•  Process  3.2 

—  DISPLAY  to  user  the  active_tr 
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GET  from  user  the  cancel_tr 
PUT  canceled_tr  into  CANCELED 
Output  —  canceled_tr 


E3  Routing 

E31  Automatedrouting 

•  Input  —  active_tr 

•  Process  —  TBD 

•  Output  —  active_tr 
E32  Manual  routing 

•  Liput  —  active_tr 

•  Process  —  TBD 

•  Output  —  active_tr 

E4  Approvals 

E41  Requester  approval 

•  Input  —  funded_tr,  requester_approval 

•  Process  1.5 

—  DISPLAY  to  user  the  funded_tr 

—  GET  from  user  the  requester_approval 

—  IF  requester_approval  is  Yes,  THEN 

—  SET  in  tr  the  requester_approval  to  Yes 

—  SET  in  tr  the  request_date  to  today’s  date 

—  SET  in  tr  the  inboxjocation  to  supervisor 

—  ELSE 

—  GET  from  user  the  explanation 

—  SET  in  tr  the  requester_approval  to  No 

—  SET  in  tr  the  explanation 

—  SET  in  tr  the  inboxjocation  to  secretary 

—  ENDIF 

•  Output  —  requested_tr,  rejected_tr 
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E42  Supervisory  approval 

•  Input  —  requested_tr,  supervisory_approval 

•  Process  1.6 

—  DISPLAY  to  user  the  funded_tr 
—  GET  from  user  the  supervisory_approval 
—  IF  supervisory_approval  is  Yes,  THEN 
—  SET  in  tr  the  supervisory_approval  to  Yes 

—  SET  in  tr  the  request_date  to  today’s  date 

—  SET  in  tr  the  inbox_location  to  budget 

—  ELSE 

—  GET  from  user  the  explanation 

—  SET  in  tr  the  supervisory_approval  to  No 

—  SET  in  tr  the  explanation 

—  SET  in  tr  the  inbox_location  to  requester 

—  ENDIF 

•  Output  —  completed_tr,  rejected_tr 
E43  Fund  source  approval 

•  Input  — completed_tr,  fund_source_approval,  standard_doc_no 

•  Process  2.1 

—  DISPLAY  to  user  the  completed_tr 

—  GET  from  user  the  fund_source_approval 

—  IF  fund_source_approval  is  Yes,  THEN 

—  SET  in  tr  the  fund_source_approval  to  Yes 

—  SET  in  tr  the  inbox_location  to  certification 

—  SET  in  tr  the  standard_doc_no 

—  ELSE 

—  GET  from  user  the  explanation 

—  SET  in  tr  the  fund_source_approval  to  No 

—  SET  in  tr  the  explanation 
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SET  in  tr  the  inbox_location  to  requester 


—  ENDIF 

•  Output  —  certifiable_tr,  rejected_tr 

E5  Interface  with  legacy  systems 
E51  Build  block 

•  hiput  —  N/A 

•  Process  2.3 

—  PUT  to  SOMARDS  the  block 

—  GET  from  SOMARDS  the  retum_message 

•  Output  —  N/A 
E52  Certify  funds 

•  Input  —  certifiable_tr 

•  Process  2.2 

—  GET  from  certifiable_tr  the  funds 

—  PUT  to  SOMARDS  the  block,  funds 
—  GET  from  SOMARDS  the  retum_message 

—  IF  retum_message  is  OK,  THEN 

—  SET  in  tr  the  certification  to  Yes 

—  ELSE 

—  SET  in  tr  the  to  certification  to  No 

—  SET  in  tr  the  explanation  to  retum_message 

—  SET  in  tr  the  inboxjocation  to  requester 

—  ENDIF 

•  Output  —  certified_tr,  rejected_tr 
E53  Reconcile 

•  Input  —  N/A 

•  Process  2.4 
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—  PUT  to  SOMARDS  the  block,  reconcile 

—  GET  from  SOMARDS  the  retum_message 
OuQ)ut  —  N/A 


E6  Inquiries 

E62  Status 

•  Input  —  active_tr 

•  Process  6.2 

—  GET  current  status  from  ACTIVE 

—  DISPLAY  to  user  the  status 

•  OuQ)ut  —  status 
E63  Generate  Report 

•  Input  —  active_tr,  report_type 

•  Process  6.3 

—  DISPLAY  to  user  report 
—  DISPLAY  to  user  active_tr 
PRINT  DD1610 

•  Ouq)ut  —  report,  DDl  6 1 0 
E64  Show  Travel  Details 

•  Input  —  active_tr,  display  details 

•  Process  6.4 

—  DISPLAY  to  user  tr_details 

—  PRINT  tr_details 

•  Output  —  tr_details 

E7  Navigation 

E71  Navigate 

•  Input  —  TBD 

•  Process  —  TBD 

•  Ouq)ut  —  TBD 
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E72  Logout 

•  Input  —  N/A 

•  Process  —  TBD 

•  Output  —  N/A 

6.  Data  Dictionary 

While  DFDs  and  pseudo-code  (structured  English)  are  important  to  system  specifications, 
additional  information  is  required  for  a  complete  analytical  model.  The  content  of  each  data  or 
control  item  should  be  more  fuUy  identified.  A  data  dictionary  is  a  quasi-formahsm  for 
describing  content  of  information  as  it  flows  through  the  system.  The  standard  notation 
conventions  are 


Notation 


[i] 

{>” 

(  ) 

*  * 


Meaning 

is  composed  of 
and 

either  -  or 
n  repetitions  of 
optional  data 
comments 


Travel  1.0’s  data  dictionary  appears  next.  Each  left-handed  element  is  taken  from  the  DFD 
and  the  Process  Narrative  model  of  the  system.  Each  of  these  data  items  is  then  given  an 
expanded,  unambiguous  definition  in  the  right-hand  column. 

acct_citation  =  *Accoimting  Citation* 

(alphanumeric) 

action  =  ** 
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ACTIVE  = 

active_tr  = 

advance  = 

advance_auth  = 

advance_info  = 

air_cost  = 

airline_info  = 

airline_info_ret  = 


{active_tr} 

♦Travel  Request  at  some  point  in  the  approval  cycle* 

♦Amount  of  advance* 

♦units:  dollars* 

♦Advance  authorized* 

[“Yes”  I  “No”] 


[advance_auth  +  advance] 


♦Airfare* 

♦units:  doUars* 

[airline_info_to  +  airline_info_ret] 

♦Airline  information  return  trip* 

[r_ffom_airport  +  r_depart_flight_no  +  r_depart_city  + 
r_depart_state  +  r_depart_date  +  r_depart_time  +  r_to_airport  + 
r_connection_flight_no  +  r_connection_city  +  r_connection_state 
+  r_connection_date  +  r_connection_time  +  r_arr_airport 
r_arr_city  +  r_arr_state  +  r_arr_date  +  r_arr_time] 
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airline_info. 


arr_airport 


arr_city  = 


arrdate  = 


arr  state  = 


airtime  = 


atm  stams 


batch_iio  = 


to  =  *Airline  information  to  destination* 

[ffom_aiiport  +  depart_flight_no  +  depart_city  +  depart_state 
+depart_date  +  depart_time  +  to_airport  +  connection_  flight_no  + 
connection_  city  +  coimection_state  +  connection_date  + 
connection_time  +  arr_airport  +  air_  city  +  arr_date  +  arr_state  + 
arr_time] 


*Arriving  to  airport* 
{alphabetic_character> 

*Arriving  to  city* 
{alphabetic_character> 

*Arriving  Date* 
*format:  MMDDYY* 
{date} 

*Airiving  State* 
{legal_character} 


*Arriving  Time* 
{numeric_digit} 

** 

{alphabetic_character} 
*SOMARDS  batch  number* 
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be_passenger  = 

blank_tr  = 

blk_no  = 

blk_tkt_dt  = 

block  = 

boq  = 

CANCEL  = 

cancel_tr  = 

canceled_tr  = 


*Will  be  a  passenger  in  POV  or  rental  car* 

[“Yes  I  No”] 

*Travel  Request  with  the  requester  and  requester  profile  info 
filled*  [requester_userid  +  user_info  + 

profile_info] 

*SOMARDS  block  number* 

“ARL” 

*SOMARDS  block  ticket  date* 

*format:  MMDDYY* 

{date} 

*SOMARDS  build  block  data* 

[tms_cd  +  user_auth_key  +  cmd_dsg  +  update_code  +  bIk_no  + 
blk_tkt_dt  +  tot_blk  +  batch_no  +  tot_batch] 

*Govemment  Quarters* 

[“Yes  I  No”  ] 

{canceled_tr> 

*Travel  Request  canceled  by  traveler,  supervisor  or  budget* 

*Travel  Request  that  has  been  canceled* 

[active_tr  +  cancel_tr] 
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certifiable_tr  = 


certification  = 


certified_pr  = 


city  = 


completed_tr  = 


connection_city  = 


connection_date 


connection_flight 


connection_state 


*Travel  Request  that  has  fund  source  approval* 
[completed_tr  +  fund_source_approval] 

*SOMARDS  Certification* 

[“Yes  I  No”] 

*Travel  Request  that  has  been  certified  by  SOMARDS* 
[certifiable_tr  +  certification] 

** 

{alphabetic_  character} 

*Travel  Request  that  has  been  approved  by  the  supervisor* 
[requested_tr  +  supervisory_approval] 

** 

{alphabetic_character  } 

** 

*format:  MMDDYY* 

{date} 

** 

{alphanumeric} 

{legal_character  } 
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connection_time  = 

corrected_tr  = 

corrections  = 

costs  = 

cum_btch_value  = 

DD1610  = 

depart_flight_no  = 

depart_city  = 

depart_date  = 

department  = 


{numeric_digit} 

*Travel  request  that  has  been  corrected  by  the  user* 

[rejected_tr  +  corrections] 

*Coirections  to  a  rejected  travel  request* 

*Total  estimated  cost  of  tdy* 

[perdiem_cost  +  air_cost  +  other_cost  +  registr_cost  +  etc-costs] 
*units:  dollars* 

*SOMARDS  cumulative  batch  totel  for  the  days  certification* 
*units:  dollars* 

♦Printout  of  form  DD1610* 

*Departure  Flight  Number* 

{alphanumeric} 

♦Departure  City* 

{legal_character  } 

♦Departure  Date* 

♦format:  MMDDYY* 

{date} 

♦Organization  Element(Dir/Div/Branch)* 

{legal_character} 
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depart_state  = 

depart_time  = 

display_details  = 

EMPLOYEE  = 

employee  = 

eor  = 

etc_costs= 

explanation  = 

first_name  = 

from_airport  = 


*Departure  State* 

{legal_character} 

♦Departure  Time* 

{numeric_digit} 

♦Display  to  user  specific  travel  information* 

{employee} 

♦Employee  information  -  the  bare  minimum  should  contain* 
[user_info  +  {roles}] 

♦Funding  element  of  resource* 

{alphanumeric} 

♦Other  costs* 

♦units:  dollars* 

♦Rejection,  cancellation,  or  return  explanation* 
{legaLcharacter} 

♦A  person’s  first  name* 

{alphabetic_character  } 

♦Departure  airport* 

{alphabetic_character  } 
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from_city  = 


from_date  = 


from_mode_trans  = 


from_state= 


fund_source  = 


fund_source_approval  = 


funded_tr  = 


funds  = 


*Departure  city* 

{legal_character  > 

*Departure  date* 

*fonnat:  DD-MON-YY* 

{date} 

*Mode  of  transportation  “TO”  the  TOY  site* 

{legal_character} 

*Departure  State* 

{legal_character  } 

|jo_no  +  acct_citation  +  eor_l  4eor_2] 

{alphanumeric} 

*Budget  Analyst  approval  of  fund  source* 

[“Yes  I  No”] 

*Travel  request  with  a  fund  source* 

[unfunded_tr  +  fund_source] 

*Funding  information  for  SOMARDS  certification* 

[tms_cd  +  user_auth_key  +  cmd_dsg  +  update_code  +  bIk_no  + 
blk_tkt_dt  +  batch_no  +  rej_rept_director  +  doc_ref_no  +  jo_no  + 
eor  +  act_amt] 
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gov_installation  = 


gov_phone  = 


grade = 


have_passenger  = 


hotel_address  = 


hotel_name  = 


hotel_phone  = 


in_around_tdy  = 


inbox  = 


mbox_inquiry  = 


*Name  of  government  installation* 
{alphabetic_character} 

*Goverment  installation  phone  number* 
{numeric_digit> 

*Traveler’s  grade* 

{alphanumeric) 

*Will  have  passenger(s)  in  POV  or  rental  car* 
[“Yes  I  No”] 

{alphanumeric) 

{alphabetic_character) 

** 

{numeric_digit) 

♦Rental  car  authorized  in/around  TDY  site* 
[YesINo] 

♦Travel  requests  requiring  action  from  user* 
{active_tr) 

*Sf! 

TBD 
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inbox_location  = 


itinerary_info  = 


itmerary_from  = 


itinerary_ret  = 


itinerary_to  = 


jobtitle= 


jo_no  = 


last_name  = 


leave_auth  = 


♦Current  Travel  Request  Location* 
TBD 


[itinerary_from  +  itinerary_to  +  itinerary_ret] 

♦Traveler’s  “FROM”  itinerary  information* 

[from_state  +  from_city  +  ffom_date  + 
from_mode_trans] 

♦Traveler’s  “RETURN”  itinerary  information* 

[ret_state  +  ret_city  +  ret_date  +ret_mode_trans] 

♦Traveler’s  ‘To”  itinerary  information* 

[to_state  +  to_city  +  to_date  +  tdy_days  +  perdiem  + 
to_mode_trans] 

♦Official  title  of  user* 

{alphabetic_character> 

♦Funding  Job  Order  Number* 

{alphanumeric} 

♦A  person’s  last  name* 

{alphabetic_character} 

♦Leave  authorized  during  TOY* 

[YesINo] 
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leave_days  = 


location  = 


lodging_info  = 


lodgmg_reniarks  = 


mail_stop  = 


mi  = 


mode_type  = 


name  = 


other_cost  = 


*Number  of  leave  days  taken* 

{numeric_digit} 

*Official  duty  station* 

{alphanumeric} 

*Travel  lodging  information* 

[boq  +  gov_installation  +  gov_phone  +hotel_name  + 
hoteLphone  +  hotel_address  +  lodging_remarks] 

*Remarks  pertaining  to  lodging  accommodations* 
{alphanumeric) 

*Mail  stop  or  department* 

{legal_character} 

*Middle  initial* 

{alphabetic_character  > 

*Type  of  Transportation* 

{legal_character} 

** 

[first_name  +  last_name  +  mi] 
{alphabetic_character> 

*Total  estimated  “OTHER”  costs* 

[rental_cost  +  etc_cost] 

*units:  dollars* 
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partial_tr  = 


passenger  = 


perdiem  = 


perdiem_cost  = 


phone_no  = 


pov_mode_trans 


pov_mode_trans^ 


pov_passenger= 


[blank_tr  +  purpose_tdy  +  proceed_date,  itinerary  + 
leave_days  +  costs] 

♦Passenger  in  POV  or  rental  car* 

[have_passenger  +  be_passenger] 

♦Perdiem  rate* 

♦units:  dollars* 

[perdiem  *  tdy_days] 

♦units:  dollars* 

♦Phone  number* 

<numeric_digit} 

.info  =  ♦♦ 

[pov_mode_trans  +  pov_to_ffom_mmode] 

♦  Traveler  selects  reason  for  using  his/hers  POV  (more 
advantegeous  to  gov.  or  limited  reimbursement 

from  gov)* 

♦Name  of  gov.  employee  that  the  traveler  will  be  a  passenger  to 
his/hers  POV* 

{alphabetic_character} 
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pov_to_froin. 


pov_type= 


proceed_date 


profile_info 


puipose_tdy 


reconcile  = 


registr_auth 


registr_cost  = 


rejected_tr  = 


.mmode  =  *Traveler  uses  POV  to/from  rental  car  pick-up* 

[Yes  I  No”] 

*Type  of  POV* 

{alphabetic_character} 

=  *Proceed  date  of  TDY* 

*format:  MMDDYY* 

{date} 

*Traveler’s  profile  information* 

[ssn  +  grade  +  atm_status  +  jo_no] 

*TDY  purpose* 

{alphabetic_character} 

*End  of  the  day  SOMARDS  reconcile  info* 

[tms_cd  +  user_auth_key  -i-  cmd_dsg  +  update_code  +  blk_no  -i- 
blk_tkt_dt  +  batch_no  +  tot_blk  +  tot_batch  +  ty_act_cd  + 
cum_btch_value  +  variance] 

*Registration  fees  authorized* 

[YesINo] 

*Registration  fee  not  included  on  DD1556* 

♦units:  dollars* 

♦Travel  request  that  has  been  rejected  by  Supervisor  or  Budget* 
[active_tr  +  explanation] 
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rej_rept_director  = 


remarks= 


rental_car_agency  == 


rental_car_info  = 


rental_car_phone  = 


rental_cost  = 


rental_passenger= 


report  = 


report_type  = 


*SOMARDS  REJ-REPT-DIRECTOR* 

“R” 

{alphanumeric} 

*Name  of  rental  car  agency* 
{alphabetic_character  } 

♦Rental  car  information* 
rental_car_agency  +  rental_car_phone 

♦Rental  car  agency  phone  no.* 

{numeric) 

♦Rental  car  cost* 

[tdy_days  *  35.00] 

♦units;  dollars^ 

♦Name  of  gov.employee  that  the  traveler  will  be 
passenger  to  his/hers  rental  car^ 
{alphabetic_character} 

** 

TBD 

♦Type  of  report  to  generate* 

TBD 
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request_date  = 


*  System  date* 


request_info  = 


requested_tr  = 


requester_approval  = 


requester_userid  = 


ret_city  = 


ret  date  = 


ret_mode_trans  = 


ret  state  = 


[purpose_tdy  +  proceed_date  +  itmerary_info  +  pov_mode_trans, 
advance_mfo  +  special_req  +  costs] 

*  Travel  request  that  has  been  approved  by  the  requester* 
[funded_tr  +  requester_approval] 

*  Approval  from  requester* 

[“Yes  I  No”] 

** 

{userid} 

*  Return  City* 

{legal_character  > 

*  Return  Date* 

*format:  MMDDYY* 

{date} 

*  Mode  of  transportation  from  the  TDY  site* 

{legal_character} 

*  Return  State* 

{legal_character  } 
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retum_message  = 


r_arr_airport= 


r_arr_city= 


r  arr  date= 


r_  arr_state  = 


r  air_time= 


r_connection_city= 


r  connection_date= 


*  Message  returned  from  SOMARDS  process* 

[processing  complete  I  bad  user_auth_key  I 

wrong  update  code  I  blk_no/blk_tkt_dt  already  exists  I 
accounting  class  displayed  I  blk_no/bIk_tkt_dt  doesnot 
exist  I  invalid  jo_nol  invalid  eor  I  insufficient  funds  I  duplicate 
comt_ref_no  1  cum_btch_value  I  make  changes  I  variance] 

*  Arrival  airport  return  trip* 

{alphanumeric} 

*  Arrival  City  name  return  trip* 

{legal_character> 

*  Arrival  date  return  trip* 

*format:  MMDDYY* 

{date} 

*  Arrival  state  return  trip* 

{legal_character} 

*  Arrival  time  return  trip* 

{numeric_digit} 

*  Connection  City  name  return  trip* 

{legal_character  } 

*  Connection  flight  date  return  trip* 

*format:  MMDDYY* 

{date} 
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r_connection_flight 


r  coiinection_state 


r_coiinection_time 


r_depart_city  = 


r_depart_date= 


r_depart_flight_no 


r_depart_state  = 


r_depart_time  = 


r_from_airport  = 


no  =  *  Connection  flight  time  return  trip* 

{alphanumeric} 

*  Connection  flight  state  return  trip* 
{legal_character} 

*  Connection  flight  time  return  trip* 
{numeric_digit} 

*  Departure  city  return  trip* 
{alphabetic_character  > 

*  Departure  date  return  trip* 
*format:  MMDDYY* 

{date} 

*  Departure  flight  no  return  trip* 
{alphanumeric} 

*  Departure  State  return  trip* 
{legal_character} 

*  Departure  Time  return  trip* 
{numeric_digit} 

*  Return  from  airport  information* 
[airline_info_ret] 


39 


r_to_airport 


role  = 


share_rental= 


special_req  = 


ssn= 


standard_doc 


state  = 


status  = 


status_inquiry 


*  Airport  name  return  trip* 

{alphanumeric} 

*  user  role* 

{alphanumeric) 

*  Traveler  will  share  driving  of  rental  car  with  other  gov. 
employees. 

[YesINo] 


*  Other  special  requirements  about  the  TDY* 
[passenger  +  registr_auth  +  leave_auth  +  leave_days  + 
trip_report  +  rental_car_auth] 

*  Social  security  number* 

{numeric_digit} 

no=  *  Standard  document  number* 

{alphanumeric} 

*  State  or  province* 

{legal_character  } 

TBD 

TBD 
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supervisory_approval  = 


*  Approval  from  supervisor* 
[“Yes  I  No”] 


tdy_days  = 


tdy_poc_name  = 


tdy_poc_phone  = 


tdy_site_info  = 


tdy_site_remarks  = 


tdy_site  = 


to_airport  = 


to_city  = 


*  Number  of  TDY  days 
[ret_date  -  proceed_date] 

{numeric_digit} 

*TDY  Point  Of  Contact* 

{alphabetic_character  } 

*  TDY  phone* 

{numeric} 

** 

[tdy_site  +  tdy_poc_name  +  tdy_phone  +  tdy_site_remarks] 

*TDY  site  remarks* 

{alphanumeric) 

*TDY  site  name* 

{alphanumeric} 

*  Connecting  flight  to  airport* 

{alphabetic_character  } 

*Destination  City* 
legal_character} 
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to  date  = 


to_from_iimiode  = 
to_from_tdy  = 
to_mode_trans  = 


to_state  = 


tot  batch  = 


totblk  = 


tr  = 


tr_details  = 


trip_report  = 


*Arrival  Date* 

*forniat:  MMDDYY* 

{date} 

♦Rental  car  authorized  to/from  main  mode* 

♦Rental  car  authorized  to/from  TDY  site* 

♦Mode  of  transportation  AT  the  TDY  site* 
{legal_character  > 

♦Destination  State* 

{legal_character  } 

♦SOMARDS  batch  number* 

♦units:  dollars* 

[“0.00”  I  cum_btch_value] 

♦SOMARDS  total  block* 

♦units:  dollars* 

[“0.00”  I  cum_btch_value] 

♦Travel  Request* 

♦Travel  specific  information* 

[tdy_site_info,  lodging  _info,  rental_car_info,  airline_info] 

♦Trip  report  required* 

[“Yes  I  No”] 


42 


tms  cd  = 


ty_act_cd  = 


unfunded_tr= 


update_code  = 


user_auth_key  = 


user  info  = 


userid  = 


variance  = 


variation  = 


*SOMARDS  transaction  code* 
[“003”  I  “004”  1  “310”] 


*SOMARDS  action  code* 

“C” 

*Partial  travel  request  with  additional  information* 
[partial_tr  +  tr_details] 

*SOMARDS  update  code* 

[“CM”1  “NM”] 


*SOMARDS  user  authorization  key* 
{alphanumeric} 

*User  information* 

[name  +  phone_no  +  department  +  location  +  title] 

** 

{alphanumeric} 

*SOMARDS  variance  between  tot_batch  and 
cum_btch_value  -  should  be  0.00* 

*units:  dollars* 

*  Authorized  itinerary  variation* 

[“Yes  I  No”] 
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Intentionally  left  blank. 
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